Layers and non-functional patterns

We consider the use of a hierarchically layered architecture for object-oriented systems and we look at the specification of security or other nonfunctional aspects of the system as a set of local level specifications. These specifications are realized using patterns. The enforcement of the constraints defined at a high level is performed through mappings to the lower levels. This approach is the basis for a secure system development methodology. Introduction. Security and other non-functional requirements affect all the architectural levels of a system. The Layers architectural pattern [Bus96] is therefore a good starting point to apply these requirements. Using layers we can define patterns at all levels that together implement a secure or reliable system. The main idea of the Layers pattern is the decomposition of a system into hierarchical layers of abstraction, where the higher levels use the services of the lower levels. We have discussed earlier, why all these levels must be coordinated to assure security [Fer99] and how the definition of non-functional specifications should be done at a specific level [Fer95]. Security is a very important aspect of any computing system, and has become a serious problem since institutions have opened their databases to the Internet. Most web systems in current use have not been designed with security in mind and patches have failed to make them more resistant to attacks. It is important to develop systems where security has been considered at all stages of design and at all architectural levels, which not only satisfy their functional specifications but also satisfy security and other non-functional requirements [Fer00a]. To do this we need to start with high-level models that represent the security policies of the institution. There are three models currently used by most systems: the access matrix, the Role-Based Access Control (RBAC) model, and the multilevel model. We presented patterns for these models in [Fer01]. These models can be used to define security constraints in the application. The conceptual model of the application defines the highest level and authorization constraints should also be defined at this level. The lower levels of the architecture should enforce these constraints using appropriate mechanisms. We start with a discussion of architectural levels, followed by a description of some of the patterns we are considering. We end with a general evaluation of this approach.